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Abstract 


This paper addresses the problem of describing and analysing inter- 
nally consistent data within business process workflow specifications. 
We use Rodin platform for verifying the correctness of the Event-B 
models. These models we obtain from an ontology and an associated 
set of normative constraints by applying mapping rules. The latter 
enable us to transform these specifications into Event-B modular arte- 
facts. The resulting model, by virtue of the Event-B formalism, is 
very close to a typical loosely coupled component-based implementa- 
tion of a business system workflow, but has the additional value of 
being amenable to theorem proving techniques to check and refine 
data representation with respect to process evolution. In this paper, 
we give a formal account of the design specifications defined by Event- 
B modules and perform verification and validation by using theorem 
proving techniques provided by Rodin platform. 


Keywords: Event-B, verification, validation, business process, formal 
specifications, Rodin platform. 


1 Introduction 


Business process management (BPM) is a challenging aspect of the enter- 
prise. Middleware support for BPM, as provided by, for example, Oracle, 
Biztalk and the recent Windows Workflow Framework, has met some chal- 
lenges with respect to performance and maintenance of workflow, which can 
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be directly related to the efficiency of business modeling in terms of preserv- 
ing semantics. The process of developing business models often leaves out 
meeting a requirement of specifying data in workflows, but mainly defines 
dataflow. 


The central challenge to BPM is complexity: business processes are be- 
coming widely distributed, interoperating across a range of inter- and intra- 
organizational vocabularies and semantics. It is important that complex 
business workflows are checked and analysed for optimality and trustwor- 
thiness prior to deployment. The problem becomes worse when we consider 
the enterprise’s demand to regularly adapt and change processes. For exam- 
ple, the growth of a company, changes to the market, reevaluation of tasks 
to minimize cost. All these factors require re-engineering or adaptation of 
business processes and continuous improvement of individual activities for 
achieving dramatic improvements of performance critical parameters such 
as quality (of a product or service), cost, and speed [36]. Re-engineering of 
a complex workflow implementation is dangerous, due to existing dependen- 
cies between tasks. 


Martin Hepp, et al. [24] are emphasising the notion of workflow- 
centricity of business processes, the main weakness of which is the focus 
exclusively on control flow patterns. The workflow-centricity is particularly 
true for BPEL. This brings a major disadvantage to such workflows: it be- 
comes impossible to access a business process space at the knowledge level 
which could potentially facilitate discovering of processes or their fragments 
for serving particular purposes. It is also impossible to query process space 
at the semantic level, e.g. using logical expressions and machine reasoning, 
which could help automate tasks execution. 


Formal methods can assist in meeting the challenge of complexity, as 
their mathematical basis enable us to analyze and refine a system speci- 
fication. Petri nets [30] are famous for modeling and analyzing business 
processes. However, complex systems often involve a number of different 
aspects that entail separate kinds of analysis and, consequently, the use of a 
number of different formal methods. When using formal methods engineers 
define specifications and attempt to prove their correctness applying a range 
of different tools. Verification of the specifications in this case is useful for 
it ensures that the system under question is internally consistent. It gives 
the engineers a sense of confidence that the developed specifications are 
error free and can operate correctly when implemented in a programming 
language. Validation is the process of ensuring that the developed specifica- 


Verification and Validation of 
Formal Data-Centric Business Models 319 


tion is in line with the wishes of the clients. In other words, developers check 
the specifications against the unstructured and informal documentations of 
requirements. 


A business process implementation within a BPM middleware requires 
detailed treatment of both information flow and information content. The 
abstraction gap is identified as follows: an abstract workflow that ignores in- 
formation content provides an abstract view of business processes that does 
not fully define the key aspects necessary for BPM implementation [24]. 
We argue that this abstraction gap can be addressed by developing event- 
driven data-centric workflow models in the Event-B language from an initial 
business process requirements specification. We employ a Model Driven Ar- 
chitecture approach. The initial computational independent model (CIM) 
is written as a number of requirements specifications. For this purpose we 
use ontologies and a normative language of MEASUR [17]. The method 
has an almost 30-year history and is widely used within the organisational 
semiotics community, but less well-known in Computer Science. Its roots 
lie in the philosophical pragmatism of Peirce, the semiotics of Saussure and 
Austin’s speech act theory. It is model-based, with ontologies and norma- 
tive constraints forming the central deliverables of a requirements document. 
We employ MEASUR notation because our starting point is information sys- 
tems analysis, where MEASUR has found the most application. We have 
found that MEASUR’s normative constraints lend themselves to transfor- 
mation into our languages related to the platform independent model (PIM), 
which is in our approach defined using modular artifacts of formal specifi- 
cations written in Event-B. These modular specifications are represented 
as a collection of machines that are interacting with each other via exter- 
nal variables. However, our approach for defining CIM, which is formally 
defined as a collection of norms and definitions for prescribing agents differ- 
ent patterns of behavior depending on the conditions [7], should be readily 
adaptable to a number of similar notations in use in the multi-agents and 
normative specification research communities. To further our research, in 
this paper we attempt to demonstrate a formal account of the design specifi- 
cations defined by Event-B modules and perform verification and validation 
by using theorem proving techniques provided by Rodin platform. 


The Event-B language is used for specifying, designing, and implement- 
ing software systems. The language may be used to develop software by a 
process of gradual refinement, from an abstract, possibly nonexecutable sys- 
tem model, to intermediate system models that contain more detail on how 
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to treat data and algorithms, to a final, optimised, executable system. In 
this process, 


e the first abstract model in this refinement chain should be verified for 
consistency, 


e each step in the refinement should be formally checked for semantic 
preservation. 


Consistency will then be preserved throughout the chain. This means that 
the final executable refinement can be trusted to implement the initial ab- 
stract specification. Our approach defines a transformation of MEASUR 
models to Event-B machines, permitting 


e a full B-based formal semantics for vocabularies and data manipula- 
tion carried out within the modeled workflow, which can be validated 
for consistency; and 


e an initial, abstract B model that can be further refined using the B- 
method to a final optimal executable system in an object-oriented 
workflow middleware, such as Windows Workflow Foundation. 


A notion of semantic compatibility holds over the transformed models, so 
that any property derived over the normative-ontological view of the system 
will hold over potential processes that arise from the Event-B machine. 

Different manipulations towards changing and adapting business pro- 
cesses are most often performed by domain experts at the initial require- 
ments specifications level. Use of simple tools for this purpose helps to 
solve the problem of complexity by verification of correctness and consis- 
tency of business workflows using different properties inherently provided 
by those tools. However, they do not define the nature of data flowing 
through the processes and activities. This leads to final requirements doc- 
uments developed by domain experts that are not semantically descriptive 
enough to reflect data computations involved in business process executions. 
On the contrary, design level implementations can be semantically rich and 
formal, reflecting all the important information necessary for correct and 
effective business process executions at the expense of excessive complexity 
for domain experts. Moreover, all good designs must be modular which rep- 
resents yet another challenge in terms of implementing them. The distance 
between requirements and design in terms of the degree of their semantical 
richness brings about a pronounced semantic gap. 
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This paper is a part of the research in which we develop a model-driven 
transformation from normative requirements to formal designs. This type of 
transformation is high level and requires use of non-trivial mapping rules. In 
what follows, we describe an approach of using Event-B as a formal language 
for describing the design patterns of the system [13] and demonstrate how 
these specifications can be checked for consistency. Additionally, we are 
outlining our future work of roundtrip engineering, by which we can detect 
inconsistencies in high level normative specifications. 

The paper proceeds as follows: 


e In Section 2, we sketch the nature of our normative ontology language 
of MEASUR. 


e Section 3 provides a brief introduction to Event-B specifications and 
provides its formal account by focusing on the definitions of context 
and machines; 


e Section 4 then outlines a discussion on soundness of transformation, 
definitions for normative requirements and gives a description on ver- 
ification and validation of the generated design specifications; 


e Section 5 discusses related work on enriching workflow models, on- 
tological lifting, correctness of a workflow, and integrating different 
languages. 


e Section 6 discusses the future work towards the concept of “roundtrip 
engineering” for ensuring correctness of the requirements specifica- 
tions. 


2 Normative Ontology 


Business workflows modelled by MEASUR’s ontologies and normative defini- 
tions with the elements of responsibility, agency and modality of the theory 
of normative positions specify business processes as modular actions, exe- 
cution of which depends on the modality positions and agents which bear 
responsibility for execution of those actions. The execution of actions is 
understood as a change of the state of affairs. For agents to be responsible 
to see to it that some state of affairs is obliged / permitted / not permitted 
to be true (the collocation “to see to it that” is taken from the original re- 
search on logic and theory of normative systems and means that any agent 
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in question is responsible for some state of affairs to be true), there are one 
or more pre-conditions which need to hold. In what follows, we attempt to 
describe our approach of formalizing normative specifications. 


2.1 Methodology MEASUR 


Method for Eliciting, Analyzing and Specifying User Requirements (MEA- 
SUR) represents a radically new set of norm-oriented methods for business 
systems modeling and requirements specification for software development 
17]. MEASUR is a result of more than 30 years of research in the area 
of organizational semiotics. A number of related papers and books were 
published over these years, of which the most recent ones can be found in 
9]. The overall spirit of these publications is that they see organizations as 
information systems with the set of agents, their corresponding set of poten- 
tial actions (affordances) and set of norms which govern agents’ behavior. 
MEASUR offers five phases for business modeling and software development, 
of which three the most important phases are problem articulation methods, 
semantic analysis method and norm analysis method. 


The general ontological theory is concerned with fundamental questions 
of classifying everything that exists in the world into different categories, 
describing that everything while it exists, and seeking to elicit possible hier- 
archies and dependencies among the things that make up that everything. 
Liu [17] defines the term everything as constituent notions such as thing, 
entity, individual, universal, particular, substance, event, process and state. 
These notions are embraced with the general ontological study. 

Although there are different types of ontologies related to knowledge 
and its representation, the only type of ontology that semantic analysis is 
relevant to is that which recognizes only our own behavior in accordance 
with our own ambiance. This type of ontology can be defined as a collec- 
tion of representational data that models a certain domain of knowledge or 
discourse. Everything that exists in the world is dependent on the agent’s 
behavior. In other words, the meaning of a thing is related to the ability of 
the agent to recognize that thing as a particular entity. 

Semantic Analysis has its roots in semiotics, the philosophical investiga- 
tion of signs. MEASUR applies to information system analysis a number of 
ideas and approaches from philosophy of language, drawing on the pragma- 
tism of Peirce, semiotics of Saussure and the epistemology of Wittgenstein 
and Austin. The method’s core assumption is knowledge and information 
exists only in relation to a knowing agent (a single human, a machine, or 
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a social organization). There is no Platonic reality which defines Truth. 
Instead, Truth is a derived concept that might be defined as an agreement 
between a group of agents. An agent is responsible for its knowledge. When 
a group of agents agree on what is true and what is false, they accept respon- 
sibility for that judgment. Following Wittgenstein [6], MEASUR considers 
an information system as a “language game”, a form of activity involving 
a party of agents that generates meaning. In an information-system-as- 
language-game, the meaning of data derives from usage by agents, rather 
than from a universal semantics. 

There have been a number of attempts to use semantic analysis norma- 
tive ontologies as the language for a business process management engine. 
The most widely used is Liu’s NORMBASE system [17]. In such systems, 
the ontology serves as a classification schema for business data, actions 
and agents, while norms define the conditions under which actions may be 
invoked to create and manipulate data. 

In MEASUR, an information system is viewed as a business domain 
model which identifies agents, set of actions these agents can perform (i.e. 
agents’ repertoire of behavior) and relationships, and forms of knowledge 
that can result from these actions. These concepts are identified as types 
of affordances. An affordance is a pattern of behavior of a certain agent 
provided by the environment that he is directly related to. In other words, 
environment offers a knowledge to an agent according to which the agent 
forms certain repertoire of behavior. Effectively, every concept in a MEA- 
SUR ontology is an affordance. 

MEASUR subclasses the notion of affordance as follows: 


e A business entity — such as a user account or a bank loan — is an 
affordance in the sense that it is associated with a set of permissible 
behaviours and possibilities of use. For the purpose of business process 
analysis, business entities are used to identify the main kinds of data 
that are of importance in an organization’s processes. 


e A relationship — such as a contract — between business entities or 
agents is an affordance in the sense that it is defined by the behaviour 
it generates for the parties involved in the contract. 


e Agents are affordances in terms of the actions they can perform and 
the things that may be done to them. Agents then occupy a special 
status in that they take responsibility for their own actions and the 
actions of others and can authorize patterns of behavior. 
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e Communication acts are affordances in the sense of the available ac- 
tions that the appropriate related agent or agents may perform de- 
pending on their possessed knowledge and experience. 


e The structure of a business entity, relationship or agent is given via 
a list of associated properties, called determiners. Determiners are 
properties and attributes of affordances, such as address or telephone 
number associated with a user account. 


e Units of measurement are typical data types that type determiners 
and other values associated with affordances. The latter two concepts 
are considered as affordances as their values constrain the possible 
behavior of their owners. We will assume the units of measurement 
comprise the usual basic data types available to most programming 
and design languages: that is, Bool (booleans), String (strings), Int 
(integers), Float (floating point numbers) and finite enumerations (of 
the form {v,..., Un}, where each v; enumerates a permissible value 
of the type). However, depending on the information system under 
consideration, the business analyst may add any other kind of simple, 
unstructured data type. Structured data (for example, details relating 
to a client’s bank account) should be provided as a business entity. 


The ultimate deliverable of these three stages is what we will refer to 
as a normative ontology. A normative ontology consists of what might be 
called a semi-formal requirements document, in the sense that it can be un- 
derstood readily by clients, business analysts and developers. This model 
breaks down an information system into a set of business data, communi- 
cating agents (stakeholders, departments, people, computer programs) and 
business processes that agents can invoke in order to manipulate data be- 
tween each other. The model consists of a role-and-relationships ontology 
together with a set of norms that formally define the structure and expected 
and permitted interactions within an organization and its processes. 


2.2 The Normative Perspective 


The theory of normative positions is based on the fundamental principles of 
deontic logic. Deontic logic is a formal system and represents a field of sym- 
bolic logic which is concerned with normative concepts such as obligation, 
permission, and prohibition used in contractual relationships for classifying 
actions and states of affairs [27]. The word deontic comes from Greek and 
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means “of that which is binding”. Standard Deontic Logic (SDL, KD, or 
simply D) is the most studied and axiomatically defined system of deon- 
tic logic. SDL 1) represents a monadic deontic logic because its deontic 
operator is a one-place operator, 2) builds on propositional logic, and 3) 
is formally specified by a Kripke-style semantics. SDL uses the following 
notation to denote its main concepts: ObA stands for it is obligatory that 
A and PeA — it is permissible that A. 


Deontic logic have not yet found wide application in technical areas 
such as Computer Science. However, deontic modalities could be efficiently 
used in specifying technical requirements for different business domains. For 
instance, modality “obligatory” may well model the requirement that a 
system must check whether a buyer have enough money in his back account 
before making a purchase in an on-line or physical store; and modality 
“permissible” can be applied to specify a rule that a bank may check (it is 
permissible that bank checks) credit history of a client before issuing a loan. 
More on the definition and a Kripke-style possible world semantics for SDL 
can be found in [26]. 


The theory of normative positions was originally inspired by analytical 
study of law and originated in the works of Stig Kanger [32, 33], Ingmar 
Porn [10, 11], and Lars Lindahl [20, 21]. The Kanger-Lindahl theory is 
characterized by attempts to apply modal logic — mainly standard deontic 
logic, the field of logic concerned with obligations and permissions — and the 
logic of action and agency to the concepts of legal and normative relations 
which Wesley Newcomb Hohfeld (1879-1918), an American jurist, had re- 
garded to as the fundamental legal conceptions of jurisprudence [35]. These 
normative relations are alternatively referred to as normative positions that 
take the forms of obligations, permissions, duties, and rights of agents of 
a community, society or some other form of organization. By agents here 
we mean humans, machines, or both. The Kanger-Lindahl theory also em- 
braces the formal representation of more complex normative positions such 
as entitlement, authorization and responsibility. 


Besides the areas of legal knowledge representation (e.g. representation 
of laws, regulations, legal contracts, etc.), where the theory of normative 
positions found its initial application, there are also other areas such as 
Computer Science, where the theory contributed much for formal represen- 
tation of relations between agents. For example, Jones and Sergot [1, 2] 
describe a modified version of the Kanger-Lindahl theory and attempt to 
apply it to the problem of access control and security policies specifications 
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and analysis for databases. In their attempts [2], authors illustrate by an 
example of library regulations for governing the procedures of loaning books 
that the use of formal methods in developing system specifications have to 
be taken seriously whenever it is necessary to analyze an ideal case and an 
actual one and see how the actual behavior deviates from that of ideal. Use 
of such formal methods as deontic logic, as an integral part of the normative 
system proposed by Jones and Sergot, can help in revealing the possibility 
of violations, i.e. those deviations that had actually occurred. According 
to Jones and Sergot [2], the use of deontic logic will in general allow (i) to 
reason with the specifications developed, (ii) to be able to test the internal 
consistency of the system specifications as a whole, and (iii) to use theorem 
provers to implement and test different components of the system. 

In the works of Kanger, Porn, and Lindahl [32, 33, 10, 11, 20, 21], 
deontic logic was merged with logic of action and agency to provide a for- 
mal account of complex social interactions within organizations, which can 
be related to the technical context by applying it to the multi-agent envi- 
ronment. They introduce a so-called relativised modal operator which is 
designated as E,, where a represents a responsible agent. The approach is 
partially similar to that of dynamic logic in the sense that it also assumes 
that an action, if performed, should bring about a certain state of affairs. 
For example, expression [a]A would mean that after performing action a it 
is necessarily the case that A holds. In other words, a must bring about A. 
Analogously, (a)A means that after performing action a it is possibly the 
case that A holds, or a might bring about A. 

However, in the theory of normative positions all actions are associated 
with their respective responsible agents which makes the semantics more 
expressive. When modeling business systems using this theory we now have 
to deal with the element of agent’s responsibility embedded in the process 
of bringing about new states of affairs. The overall concept is formalized by 


BAA, (1) 


which is read as “agent a sees to it that A is the case” or similarly “agent 
a brings it about that A”. It is important to note that actions in this case 
represent a relationship between agents and the state of affairs that these 
agents bring about (or are responsible for the respective states of affairs to 
be true). 


The following expressions are properties for the action operator. The 
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first axiom schema implies that the action operator is a success operator: 
F B,A- A. (2) 


It is read as: if agent a brings it about that A then A is indeed the case. 
The second property represents a rule of inference: 


If} Ao B thent (EA © EyB). (3) 


Although the approach of combination of deontic logic with action logic 
is reminiscent of that of dynamic logic by its rules and operators, the theory 
of normative positions provides higher expressivity in a way that, unlike in 
dynamic logic: (i) by using operator EA one can express different atomic 
positions agent a can be in with respect to a particular state of affairs A; and 
(ii) using £, operator gives another important advantage, namely, one can 
also formalize a normative interpersonal relationship by means of iterating 
the action operators: 

Ey Ey A. (4) 


The examples of using this form of iteration can be demonstrated by the 
following: 
EyrE,A and 7=Pek,7E,A (5) 


where the former effectively implies that agent a refrains from seeing to it 
that A and the latter means that the agent b is forbidden to prevent agent 
a from seeing to it that A. The detailed definition is described by Jones and 
Sergot in [2]. 


2.3. Formalizing MEASUR 


MEASUR’s originator, Roland Stamper, while having a firmly applied back- 
ground in system development, was influenced by ideas from philosophy of 
language and the expressive possibilities of deontic logic. However, in spite 
of drawing upon these ideas to develop the language and approach, it was 
always, first and foremost, a semiformal approach to requirements analysis, 
lacking a full formal semantics for analysis and reasoning. His latest ideas 
can be found in [18, 19] and in other of his publications. 

The way in which MEASUR currently treats norms is analogous to the 
use of OCL within UML, that is syntaxes of OCL and UML are based on 
formal languages, but within their respective methods they do not have a 
precise semantics, which we give for MEASUR. In this paper, we provide 
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what might be called a faithful formalization of MEASUR by restricting its 
norms to precisely the kind of logical language that inspired its notion of 
behavioral norm: that is, a limited version of deontic logic, combined with 
notions of agency inspired by the theory of normative positions. This will 
be defined as a first-order logic together with a straightforward semantics. 

The language proposed in this paper is somewhat more complex, due to 
its relational nature and conformance to an ontology. However, we need not 
study the full set of formulae given: we restrict our attention to a subset of 
normative formulae that correspond to the informal schema for behavioural 
norms given in Definition 1. 

A MEASUR normative definition is of the form: 


if trigger occurs and the pre-condition is satisfied, 
then agent performs an action so that post-condition 


is Obliged/Permitted/Not permissible from resulting. 


Importantly, MEASUR norms never contain deontic quantifiers within the 
trigger, pre-condition or post-condition statements. Furthermore, actual 
communication acts are only mentioned in the post-condition: the trigger 
and pre-condition statement only refer to relations from the ontology. All 
three elements of the definition can refer to agents and entities, however. 
Finally, the prescription of an agent’s responsibility and a given deontic 
obligation are only given in the implication of the constraint. 

We can therefore restrict our attention to a subset of behavioral norms 
for a given ontology that naturally preserves these syntactic constraints 
within our formalization, now defined. 


Definition 1 (Formal behavioral norms for an ontology) Consider 
any relational ontology 


(UNIT, ENTITY, AGENT, CN, COMMACT, RN, REL, DETERM) (6) 
where 


e UNIT is the set of possible units of measurement (basic data types) 
available. 


e ENTITY is a set of entities. Each entity is of the form N{a, : 
T1,.--,€n : Tn}, where N is a unique name, each a; is a unique 
determiner name and each T; € UNIT, i =1,...,n. If there are no 
arguments, then we simply denote it by N. 
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e AGENT is a set of agents. Each agent is of the form N{a,: T1,..., Gn: 
Tn}, where N is a unique name, each a; is a unique determiner name 
and each T; € UNIT, i1=1,...,n. If there are no arguments, then 
we simply denote it by N. Sets ENTITY and AGENT are disjoint. 


e COMMACT is a mapping from a unique finite set of communication 
act names CN to the set of communication acts, consists of trinary 
relationships between two agents and one entity: 


CN + AGENT x AGENT x ENTITY 


e REL is a mapping from a finite set of unique relationship names RN 
to a set of binary relationships between agents and/or entities: 


RN > AGENT UENTITY x AGENT U ENTITY 


e DETERM is a determiner, which represents a property and/or at- 
tributes of affordances. 


The set of behavioral norms over a given ontology O, BNo, is defined to 
be any formula from Formulaeg (the set of all possible formulas in ontology) 
of the form 

G + EqgD Post (7) 


where 
e D is a deontic operator Ob or Pe. 


e The only free variables occurring in the set of guards G and the set 
of definitions of norms DEF (the set of all possible definitions for 
communication acts) are agent or entity variables from Varagenr and 
VarenTITy - 


The idea of a behavioral norm is to associate knowledge and informa- 
tion with agents, who produce and are responsible for it. From a philosoph- 
ical perspective, truth is then defined as something that an agent brings 
about and is responsible for. From the perspective of determining how to 
implement a normative ontology as a workflow-based system, we view agents 
as corresponding to subsystems, business entities to specifications of data 
and behavioral norms to expected dynamic interaction protocols between 
subsystems. 
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MEASUR and, in particular, our logical restriction of MEASUR, allows 
much flexibility when detailing the intended meaning of communication acts. 
This can be done by clarifying assertions. When it comes to the question 
of implementation of a communication act, an analyst will always ask the 
client: what is entailed by this act? The client will then explain what 
changes the act is expected to make on the elements of the ontology. 

We can encode this description as a definition DEF of the act A, of 
the form 


A— DEF (8) 
and 

DEF OA (9) 
henceforth abbreviated as 

A& DEF (10) 


where DEF is any MEASUR formula not involving communication acts, 
both A and DEF sharing the same free variables. 

We are now ready to define our formal notion of a MEASUR require- 
ment analysis document. Essentially, it consists of an ontology and pairs of 
behavioral norms and definitions. These norms specify, given certain condi- 
tions are true, an agent is obliged / permitted / not permitted to see to it 
that certain state of affairs is true. These types of normative specifications 
are not descriptive enough for requirements engineers to model changes in 
states of affairs with the necessary depth of data definition. Therefore, 
we need additional annotations for our norms, which we refer to as defini- 
tions. We hereafter present this norm/definition pair as so called normative 
tableaux. 


Definition 2 (Normative tableaux) Consider any relational ontology of 
the form (6). A requirements specification consists of pairs of behavioural 
norms over O from BNo, each paired with definitions from Formulaeg of 
the form 


REQ = {(Gi > Ey; Di Ai, Ai @ DEF) | i = 1,...,n} GD 
where 


e each G; is a single guard, particular for a given norm. 


e each D; is a deontic operator Ob or Pe. 
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e A; is a single communication act. 


e The only free variables occurring in G;, DEF; and A; are agent or 
entity variables from Varaggenr and Vargntiry - 


Each pair consists of a norm and a respective definition of that norm, and 
is called a normative tableaux. 

A model M is said to satisfy REQ if it validates the quantified con- 
junction of all REQ’s normative tableaux. That is, M satisfies REQ when 


Vay: Tr e...,%: Tye 
WO a us D, A, A Ay & DEF, (12) 


Gn — Ey, Dn An \ An @ DEF, 


where x, : Ty,...,%n : Ty is the list of all free variables contained in the 


Ce 9 


formulae of the tableaux, and the sign “e” is used as a divider between 
declarations. 


We will employ two important conventions within the rest of this paper. 


Assumption 1 We will only deal with deterministic tableaux. These are 
requirements of the form 


where 
NEG(Gi) = \{Gj |i #4 i} (14) 
However, for readability’s sake, we will always write 
REQ = {(Gi — Ey i Dd; Aj, A; oO DEF;) | a Aye a} (15) 
for equation (13) keeping the NEG(G;) always implicit within the pre-conditions. 


Assumption 2 We assume that all definitions are either atomic formulae 
or else a conjunction of atomic formulae. While in theory this weakens 
the power of our specification language, it has been observed that MEA- 
SUR specifications must be reduced to a deterministic form at some stage 
of requirements, prior to being handed over to implementation and design 
experts. 
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This assumption is reasonable to employ for a wide range of business sys- 
tems: it means that, at any point in time, at most only one norm is appli- 
cable — we can never have two norms being applicable at the same time. 


Assumption 3 Given a normative requirements specification of the form 
(13), when we specify an individual norm or definition from a tableaua, 


(G > E, Ob A) (16) 
we will often write full quantification 
Var: Tl e...0eVa,: T,e(G— E Ob A) (17) 


The purpose of this is merely to indicate the types of the free variables con- 
tained within the formulae of the norm or definition. This notation should 
not be understood as restricting the interpretation of variables to be local to 
the particular norm or definition. 

It is important to note that, within the intended meaning of an entire 
specification REQ, quantification is, in fact, understood to be given on the 
outside of an entire conjunction of all tableaux. That is, if a variable x 
occurs in a number of norms within REQ, it is to be interpreted by the 
same object in its model. 


A model for an ontology together with a set of behavioral norms Bj, 

. By is one in which each norm is true for M. Depending on the model 

and the interpretation, this might be an abstract representation of a system 

execution, or might actually be an implementation of the specification: for 

example, one in which each possible world corresponds to an actual system 
state. 


2.4 Example 


In general This section will describe application of the methodology of 
specifying norms within the framework of new improved MEASUR. In for- 
malizing MEASUR, we illustrate norms as communication acts that are 
enabled by an agent, using the elements of agency and action of the theory 
of normative positions. In the framework of new improved MEASUR, in 
order to specify norms we use so called normative tableaux. Tableau is a 
table for defining norms and their data definitions. In other words, each 
normative tableau illustrates a norm as a pre-condition and a responsibility 
expression that relates an agent to a particular communication act taken 
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from MEASUR ontology. A tableau also provides further notation for these 
norms in the form of definitions, so that each norm is paired with its def- 
inition. All norms have their definitions to obtain a certain depth of data 
definition and to be able to manipulate with these data. We need these def- 
initions within our new MEASUR in order to provide ways for requirement 
engineers to define and describe data in conjunction with ontologies. 

The subject of our example is to process an order made by a cus- 
tomer using her credit card. The meaning of processing an order embraces 
herein such activities as receiving a new order, processing its data (price, 
customer’s credit card information), invoicing and dispatching an order, in- 
teractions with warehouse and rejecting an order. In performing these activ- 
ities in the order specified, we examine interaction between three involved 
players in an organized manner. 

The first player, which starts the overall process of ordering is Customer. 
This player orders products, thereby creating a new instance of order and 
sends it to the electronic ordering system, which further processes it in a 
sequence specified below. The electronic ordering system eOrder initiates 
one activity after another and at some point starts interaction with yet 
another player called Warehouse. All these activities and communications 
between different players shift the order from one state to another. All 
orders have a strict correspondence with its particular customer and all 
orders are stored in the system during their processing until they are rejected. 
The activity of rejection removes the order from the system and cancels the 
correspondence with its particular customer. 

The activities of making a purchase using our system is of the following 
order: 


1. When a customer makes an on-line order, he initiates an interaction 
with the electronic ordering system by creating a new instance of the 
order and changing the status of this order to “received”. 


2. Electronic ordering system initiates the next activity which processes 
this new order by checking order’s data and customer’s solvency. If 
this check is successful, then the status of this order changes from 
“received” to “pending”. Otherwise, if the order’s total cost is higher 
than customer’s credit card limit, then the status of his order changes 
to “rejected”, which starts the rejecting process by removing the order 
from the system. 


3. When the order’s state changes to “pending” and if the product or- 
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dered is in stock, the system initiates the process of invoicing it by 
changing its status to “invoiced”. 


4. If the order is not available in the stock, then the electronic ordering 
system initiates a communication to the warehouse by starting the 
“request_increase” activity. 


5. After successful invoicing, the order’s status changes to “dispatched” 
to indicate that the order is dispatched. 


The diagram for this example may be similar to UML’s sequence diagrams. 
But, it is different in the way of providing more expressive definitions for 
activities, interactions, and the notion of responsibility. We will employ 
this example to illustrate the use of the MEASUR methodology and its 
formalized version. 

Applying methodology In our treatment, affordances are viewed as 
classifications of things within a business system, with an ontology defining 
a type structure for the system. An actual executing system consists of a 
collection of affordance instances which possess the structure prescribed by 
the ontology and obey any further constraints imposed by an associated set 
of norms. 

In our case study, we model an electronic ordering system. The pur- 
chasing system player eOrder is related to the Customer agent and the 
Warehouse agent. Customer orders products from eOrder by initializing 
the interaction. eOrder receives data describing the order and performs fur- 
ther processing which normally includes checking availability of the product 
in the system, customer’s solvency, invoicing, dispatching, and rejecting. If 
processing is successful, the system files an invoice for the purchase and 
subsequently dispatches it. If the product is unavailable, eOrder sends a 
request to the warehouse to increase the stock to further proceed with the 
order. If processing is unsuccessful, eOrder rejects the order. 

An ontology for the purchasing system is given in Fig. 1. Agents are 
represented as ovals and business entities as rectangles with curved edges. 
Communication acts and relations are shown as rectangles, with the former 
differentiated by the use of an exclamation mark ! before the act’s name. 

All affordances (including agents and business entities) have a number 
of typed attributes, defining the kinds of states they may be in. We permit 
navigation through an affordance’s attributes and related affordances in the 
object-oriented style of the OCL. 
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EORDER 
start : Bool, end : Bool, 


CUSTOMER 
name: String 
limit : Float 


WAREHOUSE 
start, end : Bool 
stock_increase_request : 


ORDERED_BY 


in_stock : Bool, invoiced : 
Bool, processing : Bool 


Bool 


ORDERED 
(~— opveR = receiving order 
status: {received, > ! RECEIVE_ORDER 
pending, invoiced, 
dispatched, rejected} processing order 
total : Float S\| | PROCESSING_SUCCESSFUL || ! PROCESSING_UNSUCCESSFUL 
PAS een ee eee ke ee he ee ea ae ee Pe sy ‘rejecting ord feo 
eae rejecting order 
= 5 invoicing order | E u zs 
; 
i 
! INVOICE_IF_AVAILABLE ! REJECT_ORDER 
i 
od Mite a tas one se Bas sue sesen se Sass she Jeieadce 24h eee eee ouss wee | eae alle oes 


Figure 1: Example normative ontology 


The system involves processes that cross the boundaries of three subsys- 
tems: a customer agent, an order processing system, and a product ware- 
house system. These three subsystems are represented as agents in the 
ontology, Customer, eOrder and Warehouse, respectively. By default all 
agents except for Customer contain start and end attributes. All commu- 
nication acts are associated with an instance of the entity class ORDER, 
namely oo. The whole diagram is divided by the respective tracks using 
dashed lines. Each communication act or acts that occur simultaneously 
(fork or choice) are positioned in these tracks. Shaded communication acts 
are the final acts, with which the whole process terminates. The solid lines 
between the elements of the diagram represent the need for the information 
to be exchanged between them (passing arguments, defining instances for 
the relationships, etc.): agents, communication acts, entities and relation- 
ships. 


An order is associated with its customer, defined by the ordered_by 
relationship holding between the customer agent and order entity. An order 
can stand in an ordered relationship with the eOrder agent, after it has been 
successfully processed. Communication act /receive_order corresponds to 
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the initial reception of data. The Processing communication act further 
deals with the newly arrived order and checks whether the client’s credit 
limit allows for the purchase. Namely, it checks whether the total cost of 
the purchase is less than the credit limit of the customer. This condition 
results in the following outcomes: if the credit limit is lower than the total 
cost of the purchase then the system rejects the order, otherwise it initiates 
the invoicing process (denoted by the invoice_if_available communication 
act). It does so if the stock contains enough amount of the product for the 
order. If not, then the system requests to increase the stock by initiating 
request_increase, which sets flag stock_increase_request to true. Finally, the 
system dispatches the order by dispatch_order. 


Consider the communication act /receive_order from our example, cor- 
responding to the initial reception of data by the order processing system. 
The idea that this reception can only occur over orders that are not yet pro- 
cessed is captured by the normative tableaux shown in (18) and (19). Both 
relationships and communication acts are represented as logical relations in 
our language, but communication acts are not used in pre-conditions, and 
may only be placed after a Deontic operator. 


Communication acts often define resulting changes of state on related 
agents and entities. As shown in our ontology in Fig. 1, receive_order re- 
lates three affordances: agents Customer and eOrder and business entity 
Order, instances of which are used as arguments for this communication 
act. As such, this communication act should affect the following relation- 
ships ORDERED and ORDERED_BY that are involved in relating the 
pertinent affordances. The meaning of the behavioral norms are extracted 
from additional definitions, which represent their equivalent meaning. An 
equivalent meaning of the reception of an order entails a change of state of 
affairs to include a newly arrived order, the status becomes set to “received”, 
and the system initiates the processing stage by setting its attribute to true. 
This is formalized by the norm 


Vcc: Customer eV oo : Order eV e : eOrdere 
sordered_by(oo, cc) \ sordered(oo, e) > 


FE. Ob receive_order(oo,cc,e) (18) 


Verification and Validation of 
Formal Data-Centric Business Models 337 


and its definition 


Vcc: Customer eV 00 : Ordere 
Ve: eOrder e receive_order(oo, cc, e) 
ordered_by(oo, cc) \ ordered(oo, e)A 


oo.status = received \ e.processing = 1 (19) 


The norm (18) and its definition (19) form a single normative tableau for 
the communication act /receive_order. Note that we have employed the 
conventions and assumptions just given. So determinacy is implicit, and 
we are quantifying over individual formulae, to indicate types of variables. 
However, importantly, all variables — for example, oo and cc — should be 
understood as denoting the same possible interpreting object in the seman- 
tics. 


3 Event-B 


Formal languages for specifying both computer programs and systems rep- 
resent a mathematically-flavoured approach to software development which 
did not yet find a wide application in the industry in general and in the 
area of enterprise business modeling in particular. This is explained by 
the complexity of these languages as well as the high-level reasoning pro- 
cess that engineers are exposed to while developing systems. But computer 
programs and systems that are developed using formal methods have prac- 
tically proven that use of such methods leads to final designs that are much 
less error-prone and behave exactly as prescribed in their initial (abstract) 
specifications. 


In this section, we are describing a formal language which represents 
a recent evolution of the B-method, and is inspired by the action systems 
approach [28] and oriented towards specifying and reasoning about systems 
that behave in a concurrent and discrete manner. This language is used to 
define a semantically enriched and consistent model that we obtain from our 
requirements specifications. We further explicate the model that is obtained 
by virtue of the model-driven transformation from normative requirements 
and regard it as a target Event-B model of the enterprise system. 
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3.1 Background 


The process of building computer systems that behave correctly, do not in- 
volve heavy post-implementation testing and maintenance efforts, and are 
free of impossible executions, represents a difficult task that is normally ap- 
proached by initiating software development projects with the simplest and 
most general specifications. These specifications are more often regarded 
to as artefacts or models of future systems. These models are by no means 
executable and therefore must not be considered as systems themselves but 
they help us to specify the properties and the behavior of the system to be 
implemented. As [12] puts it, the model of a program and more generally of 
a complex computer system, although non-executable, allows one to clearly 
identify the properties of the future system and to prove that they will be 
present in it. 

This approach is embraced by the formal language used for modeling 
and reasoning about systems that behave in a discrete fashion. The notion 
of discrete modeling is referred to as Event-B. The Event-B language allows 
one to describe and model systems that are operated as an execution of suc- 
cessive concurrent states. Event-B has an operational semantics based upon 
predicate transformer semantics, with its origin in the Floyd-Hoare Logic of 
Dijkstra [5] and abstract state machines [38]. The number of possible states 
that the system can be in is enormous and the frequency of their occur- 
rences is very high. Therefore, the behavior of such systems is observed as 
continuous, but this does not change the very nature of the problem: such 
systems are intrinsically discrete [12]. 

In general, Event-B can define a number of different contexts, that 
serve the same role as an algebraic theory in mathematics. For example, 
we might define one context to describe the structure and axioms for the 
theory of boolean values, and another context for the structure and axioms 
of the natural numbers. The definition for context is as follows. 


Definition 3 (Event-B context) A well-formed Event-B context C for a 
set of variables is a tuple 


C = (Ze; Ver, Ag) 
where 


e ic is a signature, which is a set of collections of basic carrier set 
names and collections of constant names. 
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e Ac = {Aj,..., Am} is a set of axioms consisting of well-formed for- 
mulas of WFFs( Var) containing no free variables (FV(A;) = 0 for 
i=1,...,m). Well-formed formula is a mathematical statement that 
is syntactically and semantically correct. 


We now define the form of the Event-B machines that we consider in this 
paper. 


Definition 4 (Event-B machine) A well-formed Event-B machine M is 
a tuple 
M= (Nu, Cu, Vary, Iu, Eu) 


where 


e Ny is a unique name for the machine 
e Cy is a context for the machine (%, Varc, Ac) 


e Vary is a set of state variables {a,...,a;} = Vary disjoint from 
Varc. Disjointedness ensures that we can use variables from the set 
Varc as variables to be bound by existential and universal quantifiers 
in formulas, while variables from Vary are employed exclusively to 
denote mutable state variables of the machine, whose values affect and 
are affected by the triggering of events. 


e ly = {inv,...,inug} is a set of invariants consisting of well-formed 
formulas of WFFs(Vary U Varc) so that FV(iny,) C Vary and 
BV (iny;)N Vary = @ (i =1,...,k), where BV stands for bound vari- 
ables. The last two conditions ensure all variables used from Varg in 
each invariant is quantified, but state variables are never quantified. 


e Ey is a set of events, of the form 


nN 


Event e; = 
WHEN G; 
THEN §S; 
END 


where for some i > 0, each e; is a unique event name, G; is a set 
of guard formulas taken from WFF3(Vary U Varc) and S; is a sub- 
stitution taken from Substy(Vary). As with the invariants, we re- 
quire that the only free variables of each guard are state variables and 
that state variables are never bound: that is FV(G;) C Vary and 
BV (ngs Varg =o. for gale: 
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The machine M is written in Event-B notation as follows: 


Machine Ny 
Var ay,..-, aj Event ey =... Event e; = 
Inv invy, ..., NUE WHEN Gy, WHEN G; 
THEN 5S} THEN 5S; 
END END 


Without loss of generality, it is assumed that all Event-B machines are 
defined with respect to some overall single context C and a contextual 
signature ». 


4 Verification and Validation 


Any Event-B specification does not guarantee correctness or consistency. 
We can easily write an inconsistent specification by, for example, adding 
axioms of the form 0 = 0 and 0 # 0 to a context that includes the usual ax- 
ioms for natural numbers. Again, it is not possible to automatically detect 
inconsistencies in a specification. It is up to a specification expert to ulti- 
mately ensure the specification is consistent. However, given a specification 
S' (aset of machines) of the form S = {Mj,...,M,}, a number of properties 
can be set that, if proven, ensure a safer, more trustworthy specification. In 
particular, given a specification, it is important to prove 


e Well-formedness of any functional application and relational state- 
ments. Well-formedness of function application and relational asser- 
tions is taken as a semantic property of the model of statements, rather 
than being treated syntactically as in a typed formalism. However, by 
examining definitions of sets and set memberships given by invariants 
and the context of a specification, it is possible to prove that all func- 
tion applications and relational assertions are well-formed. Such a 
proof entails that all models of the specification will always interpret 
function applications and relations as appropriate. 


e Invariant preservation. By proving that all invariants are entailed by 
both guards and substitutions of all events, it is possible to show that 
a specification satisfies its invariants. 


Because interpretations are given over set theory, these proofs can be done 
using the axioms of set theory. Toolkits like Rodin will automatically gen- 
erate proof obligations for these conditions from a specification and allow 
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an interactive, tactic-based approach to proving proof obligations. One of 
the motivations behind mapping requirements specifications into Event-B 
design specifications is that toolkits like Rodin will then be of assistance in 
improving trustworthiness of designs by generating and discharging these 
types of proof obligations, prior to implementation. 


4.1 Soundness of Transformation 


The language proposed to define our source model is somewhat more com- 
plex, due to its relational nature and conformance to an ontology. However, 
we need not study the full set of formulas given: we restrict our attention 
to a subset of normative formulas that correspond to the informal schema 
for behavioural norms. Due to its complexity, in what follows we provide 
its short definition. 


4.1.1 Preservation of Typing Theorem for Event-B 


The approach described in this paper describes a transformation mapping 
from normative requirements to Event-B constructs. This transformation 
mapping is formalized by the function ¢. This function thoroughly defines 
which element of the normative specifications transforms (or maps) to which 
element of the formal specification. Admittedly, this is a not quite trivial 
transformation function. From the B research community perspective let 
us attempt to prove a number of desirable properties of ¢ that define how 
it provides an adequate semantics for MEASUR. Formal transformation of 
a norm is provided in [7]. The complete semantic preservation theorem 
and the proof that the design implementations preserve requirements are 
described in [8}. 
Before the theorem we need to define well-formed formulas. 


Definition 5 (Well-formed formulas) The basic well-formed formulas 
of Event-B with signature % over variables Var, BWFF (Var), take the 
form 

SiC Se 

Si Cc So 


ees 
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for any P € Cy. €,€1, 2 € Termy(Var), where Termy( Var) is a set of all 


variable terms in signatures; and S, 51,52 € 5s, where Sy is a collection of 
all set names for %, which is defined as follows: 


e ifseEesS, then s € Sy 
e if 51,59 € S, then 8, 3 9 € Sy 
e if 51,59 € S, then 51 xa € Op 


The well-formed formulas of Event-B with signature % over variables 
Var, WFFs(Var) are defined recursively: 


e if F © BWFF3( Var) then F € WFF3( Var) 


e if fF, Fo © WFFS(Var) then Fy \ Fo, Fy > Fo,7F, € WEFs( Var) 


e if FWFFs(Var) and « € Var thenV 2.F,i2.F € WFFS( Var) 


Theorem 1 (Preservation of typing) Assume REQ is a set of behav- 
ioral norm/definition pairs over an ontology O each of the form 


REQ = {(G; > Ey; Ob Aj, Ai; & DEF;) | t= Ay isg th (20) 


Let S be the set of machines generated by applying a model-driven trans- 
formation function @ over each norm in REQ 


S = o(REQ) (21) 


so that S consists of BWFFs( Var) formulas, where Var are taken from the 
agent and entity variables of O and & is taken from the signature of O. 


Consider any norm/definition pair (otherwise referred to as ‘tableaux’ 
in [29]) defined as 


where M is a modality operator taken from deontic logic. Then 


e Given any agent variable Fo a: A{...} occurring in N, there is a 
machine M, in S corresponding to a. 
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e Given any entity variable /o e: E{k : Ti,...,ln : Tn} occurring in 
REQ, we can use the notation of delimiters to denote that the following 
expressions are located in machine My: 


Tee B'eM 


"AE BOT 1E€ Mm 


"fi, € E> Ty 1€ My 


Proof: By inspection of each of the cases in the transformation. 


Definition 6 Assume REQ is a set of behavioral norm/definition pairs, 
each of the form (20). Let S be the set of machines generated by applying @ 
over each norm in REQ (21). Given a model M of a S, we define a state 
o of M to be a non-intermediate state if, and only if, M,o FE Rn = L for 
any flag variable Ry, any norm N € REQ. Flag variable Ry is a shared 
variable of type boolean that serves as a flag between two communicating 
agents. 


Because inter-agent communication is always modeled using the boolean 
flag variables, each of the form Ry (any norm NV), a non-intermediate state 
denotes the state of the system that is not between stages of transmission 
of information from one machine to another via the shared flag variables. 


Assumption 4 We will be assuming all flag variables are initialized to be 
L within any initial state of the transition semantics. That is, we will 
assume a machine always begins in a non-intermediate stage: a reasonable 
assumption. 


Lemma 1 Assume REQ is a set of behavioral norm/definition pairs, each 
of the form (20). Let S be the set of machines generated by applying ¢ over 
each norm in REQ (21). Take any model M that satisfies S. Consider any 
norm/definition tableaux of the form (22). If we have a state o and o’ such 
that the model transformation of the definition provides a shift in the state 
from o to oa’: o! =[¢(DEF)|o; then we know that 


M,o’ | toB(DEF) 


where toB( DEF’) is a B representation (written in Event-B) of the definition. 
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Proof: By a straightforward induction over the possible forms of DEF, 
using the definition of @. 

We are now ready to show an important soundness property of the 
transformation. The intuitive meaning of a norm G + Ey.g,} Ob A is 
that, given G holds, the agent b must make A hold. Because we map G to 
a guard and A to an action of a particular event and b to a machine that 
contains the event, we would expect @ to preserve this intuitive meaning: 
that is, we would expect that whenever the guard corresponding to G is 
satisfied, the machine corresponding to 6 must always perform the action 
associated with A. 

We prove this now, formally. 


Theorem 2 Assume REQ is a set of behavioral norm/definition pairs, each 
of the form (20). Let S be the set of machines generated by applying ¢ over 
each norm in REQ (21). Take any model M that satisfies S. Consider any 
norm/definition tableaux of the form (22). For any non-intermediate state 
oa of M such that 

M,o — toB(G) 


there is a transition to state a’ caused by event eventy € Mg such that 


Sa SSeS oa nso 


where we know that the B machine interpretation of A’s definition becomes 
true in state o! 
M,o’ — toB(DEF) 


Proof: We use the definition of ¢@ and the transitional semantics of B 
machines. There are two cases, depending on the form of A. 


e If Ais of the form R(p, b’, b), where p: P{...}, P{...} © ENTITY, b: 
B{...$, B{...} © AGENT, 6’: B’{...}, B’'{...} © AGENT and Re 
COMMACT (type for communication acts used in the requirements 
definitions) and where the two agent types are different, so B{...} 4 
B’{...}, then we take the post-condition E, Ob R(p, b’, b), in which 
case by the definition of ¢ we know that there is an event named 
eventy in the machine Mg € S of the form 


“ Bvent eventy = 
WHEN GUARDy(G)* eis 
THEN ¢y(DEF); Ry := 1 
END 


(23) 
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where 


GUARDw(G)* = GUARDn(G)/G'A Ryn =T= 
(toB(G)/G') A Rn =T (24) 


and there is an event comEventy in machine Mp: 


" Bvent comEventy = 7 
WHEN Gi, E Evy, 
THEN Ry := T 
END 


(25) 


where G’ = GUARDN(G) |gtvar(My))= toB(G) leeevarcu,,) and 
ExtVAR are a class of external variables, by virtue of which a variable 
sharing is implemented in Event-B. 


Now, assuming a state o such that 


M,o — toB(G) (26) 


it cannot be the case that M,o - GUARDy(G)* holds by (24), be- 
cause 


MoF- Ry =L 


by assumption. However, by (26) it must be the case that M,o / Gy 
(because Gh, = GUARDn(G) |ZxtVAR(M,,)> 20d the restricted form of 
a conjunctive formula should hold if the original formula holds over a 
state). Consequently, we know that 


(S, o) MON ($,01) 
where 01 = [Req := Tlo. So 
M, o1 F Rea = T (27) 


Furthermore, because all other events are generated from norms that 
exclude each other’s guards, oj is the only such state that can follow 
from o. By (26) and the fact that G (and so toB) do not contain any 
reference to Ry, we have 


M,o1 - toB(G) (28) 


346 Timur Umarov 


But then it must be the case that 


M,o1 — GUARDy(G)* (29) 


by (24), (27) and (28) because GUARDy(G)* = (toB(G)/G’)A Ry = 
T. Finally, by definition of the executable semantics, we know that 
there is a state o’ such that 


(Sai PN ea! 


where o’ = [6(D); Rea := Llo, and so, by Lemma 1, M,o’ — 
toB(DEF). 


Furthermore, because all other events are generated from norms that 
exclude each other’s guards, a’ is the only such state that can follow 
from 01, as required. 


e The proof is very similar for the case where R(p,b’,b), where p : 
P{i.3, Pic} COENTITY, 6 2 Bi), Bt. € AGENT, 6” + 
B'{...}, BY{...} © AGENT and R € COMMACT and where the two 
agent types are the same, so B{...} = B’{...}. The main difference 
is that the transitions are occurring within the same machine, rather 
than out of it — however this does not affect the argument over the 
transition semantics, which is essentially the same as the dual machine 
case above. 


The analogous case for the Pe modality holds similarly. 


4.2 Validation of the Specification 


One of the requirements of formal specifications is to prove that they are 
internally consistent. We are particularly interested in checking whether 
assignment statements of events preserve the guards and invariants of the 
generated Event-B model. The Event-B language (similarly to B-method) 
defines proof obligations for substitutions (or events). Discharging these 
proof obligations presents a form of specification validation. 

For the purposes of validation of our specifications we have used the 
Rodin platform. The Rodin platform is an extensible application for refine- 
ments and mathematical proofs in Event-B, which is based on the Eclipse 
integrated development environment. Figs. 2 and 3 show our Event-B spec- 
ifications in the Rodin platform. 
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Let us now illustrate the proving perspective of the Rodin platform. 
Table 1 shows that 12 proof obligations were proven automatically. Formal 
designs with proof obligations that are proven automatically are said to be 
well-specified. For example, proof obligation of event receive_order is the 
following predicate: 


(1) status € Order + STATUSA 
(2) receive_order gyi = T \ 700 € ordered 
=> 
(3) status < {00 + received} € Order + STATUS 


(30) 


This predicate means that given invariant (1) and guards (2) hold, the 
assignment expression status(oo) := received applied to the invariant must 
also hold (3). According to Table 1, all 12 generated proof obligations for 
machine e were proven automatically. Machines cc and w do not have 
expressions that change values of state variables and therefore no proof 
obligations were generated for these machines. It is important to define 
specifications which provide proof obligations that are easy for the theorem 
provers to discharge. Otherwise the specifications have to be rewritten in a 
different manner which helps simplify the proving process. 


Table 1: Proof obligations 


Machine || Proof Obligations | Automatic | Interactive 
cc 0 0 0 
e€ 12 12 0 
w 0 0 0 
Total 12 12 0 


5 Related Work 


There are a number of related approaches for enriching workflow models [22, 
23]. In one of them the authors describe a transformation from BPEL4WS to 
full OWL-S ontology to provide missing semantics in BPEL4WS. BPEL4WS 
does not present meaning of a business process so that business process 
can be automated in a computer understandable way [34]. They are using 
overlap which exists in the conceptual models of BPEL4WS and OWL-S and 
perform mapping from BPEL4WS to OWL-S to avoid this lack of semantics. 
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MACHINE INVARIANTS 
E invl : receive _order_call ¢ BOOL 
SEES inv2 ; oo € Order 
FOS Cc inv3 : ordered ¢ Order 
inv4 ¢ status ¢ Order + STATUS 
VARIABLES inv5 : processing € BOOL 
receive_order_call inv6 =:  ordered_by ¢ Order 
aeduied inv? : total ¢ Order-N 
status inv8 : limit eN 
processing ve process _successful_call ¢ BOOL 
ordered_by invl® :  process_unsuccessful_call ¢ BOOL 
total invll :  invoice_if_available_call ¢ BOOL 
Vana invi2: in-stock ¢ BOOL 
process_successful_call . Ee ; ; 
process_unsuccessful_call inv13 4 order_invoiced ¢ BOOL 
invoice if available call invl4 : dispatch_order_call ¢ BOOL 
in_stock 7 7 inv15 : reject_order_call ¢ BOOL 
order_invoiced invl6 =: request_increase_call ¢ BOOL 


dispatch_order_call 
reject_order_call 
request_increase_call 


Figure 2: Variables and invariants of machine e represented in the Rodin 
platform 


EVENTS 

receive_order . process successful o 

WHICH IS WHICH IS 
ordinary ordinary 

WHEN HEN 
grdl receive_order_call=TRUE ~ : cit are aati 
ard2 :  oogordered orcs  jeceorcerc 

THEN grd3 : processing=TRUE 

. _ grd4 +: total(oo)<limit 

actl 3 ordered=orderedu{oo} ond ; statustoal=neecived 
act2 : ordered_by=ordered_byu{oo} THEN 
acts : status(oo)=received act1 E status(0o)=pending 
act4 : ~~ processing=TRUE act2 : process successful_call=FALSE 
act5 2 receive_order_call=FALSE END 

END 


Figure 3: Events receive_order and process_successful of machine e repre- 
sented in the Rodin platform 


Another work is using the example of BPEL processes which should be 
converted to semantically enriched specifications. All data (stored in process 
models) must be augmented by references to ontologies [24]. They refer this 
augmentation to as ontological lifting because input business processes must 
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be expressed using richer constructs provided by ontologies. However, from 
the perspective of web services, systems support only part of the process 
space representation which is reduced to the patterns of message exchange 
(choreography) and the control and data flow in the combination of multiple 
Web services (orchestration) [25]. 

Others [31] advocate the idea of ensuring the correctness of a workflow 
by making protocol specifications data-aware through expressing actual data 
content rather than message names. Workflow validation cannot be com- 
plete unless this abstraction is eliminated. They present CTL-FO* tool, 
an extension over Computation Tree Logic that includes first-order quan- 
tification on state variables in addition to temporal operators, and which is 
adequate for expressing data-aware constraints. 

There is also a variety of research directed towards semantic enriching 
of Petri net business processes. The authors were proposing to enrich the 
semantics of Petri nets by combining it with OWL language. Represent- 
ing Petri nets in combination with OWL is a way to make data computer- 
interpretable for flexibility, ease of integration and significant level of au- 
tomation of loosely coupled business processes [3]. In this work, authors 
are trying to define Petri net models using OWL framework which entails 
horizontal way of integration. In other words, they are defining semantic 
metadata for business processes described by Petri nets. 

There were also several results on integrating Petri nets and Z. In one 
of them [37], authors describe a thorough integration definition of Petri 
nets and Z which results in so called PZ nets for specifying concurrent 
and distributed systems. In this work, Petri nets are used to define the 
overall structure, control flow and dynamic properties and Z is applied for 
specifying tokens, labels and constraints of the system. This result is based 
on the previous more preliminary work on integrating Petri nets and Z 
[4]. Another work [16] have used Z to specify certain aspects of restricted 
hierarchical coloured Petri nets. Namely, the authors have used Z schemas 
to define the metamodel of a hierarchical colored Petri net and operation 
for specifying the transitions in a specific colored Petri net. 


6 Conclusion and Future Work 


Business process management is an evolving area of the enterprise. There 
are a number of problems in the enterprise where modelling workflows is 
of major importance. These problems can be related to specifying a new 
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business model or reconfiguring existing workflows to adapt the latter to the 
changes that may happen. Developing a new business model with dynam- 
ically interacting entities and agents or working with the existing system 
requires skills, knowledge (both technical and non-technical), and relevant 
modeling tools. 


In seeking to address this concern, this paper has described our formal 
approach of mapping the two levels of abstraction in order to provide a 
connecting bridge from requirements to design. Section 2 has provided a 
background information on fundamentals of speech act, normative relation- 
ships and the philosophy behind it. It also described our CIM, which is 
represented as a combination of the MEASUR ontologies and the theory of 
normative positions limited to the kinds of norms used in MEASUR. The 
MEASUR ontologies are comprised of entities, agents, relationships between 
them, and communication acts, thus representing a static information about 
the model. Our set of norms in turn constrains the behaviour of agents in 
our ontology by specifying what agent is obliged / permitted / not permitted 
to perform action under certain conditions. 


Continuing on defining formalisms, we have described the Event-B lan- 
guage in Section 3 as a PIM and provided definitions of a consistent B 
machine. The paper then proceeds with the idea of component-based mod- 
eling of Event-B and explains the choice of the language of Event-B. 


In order to define a mapping function from normative requirements to 
Event-B design, Section 4 has described a detailed definition of this mapping 
by relating different requirements components to their appropriate Event-B 
entities. With respect to its complexity, the mapping is identified as a non- 
trivial transformation which generates modular, component-based Event-B 
models from flat normative requirements. This section included 4.1 with 
the transformation soundness proofs, in which we have shown that the nor- 
mative ontologies and Event-B machines are compatible and that Event-B 
machines behave exactly as prescribed by our norms. In other words, our 
transformation guarantees that the generated Event-B models will not com- 
mit to impossible actions, behavior that is not specified in our requirements. 


The contributions described in this paper are substantial and cutting- 
edge, thereby advancing the state-of-the-art of BPM. We have defined a 
consistent B machine and operational semantics for Event-B (referred as a 
platform independent model in our approach). The operational semantics 
was formally defined by an Event-B specification, models and interpreta- 
tions and the state of a machine. We have also defined a notion of state 
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transition by virtue of describing generalised substitution and transitional 
semantics, and we have provided a definition of invariant preservation and 
model satisfaction. Our approach is one of the few attempts to formally 
embed semantics to the requirements specification via MDA and provide an 
operational semantics of Event-B to the behavioral part of the normative 
specifications. 

By virtue of implementing a transformation and generating an Event-B 
modules we have provided a formal semantics for the normative ontologies 
with correctness and validity in mind. The generated Event-B specification 
are further checked for consistency and the respective proof obligations are 
discharged. These modular specifications can further be used in refining to 
more detailed implementations. 

As a future work we argue that our method can potentially be used 
to automatically detect faults and inconsistencies in the normative require- 
ments. The concept is illustrated in Fig. 4. According to this diagram, if 


Develop requirements in 
MEASUR 


transform 


a! | ee 


Consistency check over Event-B 
specifications 


Requirements 


Machines‘ refinement 
consistent? into executable system 


Figure 4: Roundtrip engineering concept for our transformation 


the requirements are consistent, then the generated Event-B models from 
these requirements can be used for further refinement stages in order to 
obtain an executable system. In the cases of faults in the requirements, we 
plan to implement “roundtrip engineering”. If there are inconsistencies in 
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the specifications, the generated Event-B design models will have these in- 
consistencies embedded, which can be detected by the Rodin platform. The 
requirements should be revisited and checked in order to eliminate these 
faults. This is a subject of our future scientific inquiry. 
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